home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group00b.txt / 000016_icon-group-sender _Mon Jul 10 08:03:12 2000.msg < prev    next >
Internet Message Format  |  2001-01-03  |  1KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id IAA20479
  4.     for icon-group-addresses; Mon, 10 Jul 2000 08:02:58 -0700 (MST)
  5. Message-Id: <200007101502.IAA20479@baskerville.CS.Arizona.EDU>
  6. Date: Mon, 10 Jul 2000 16:57:02 +1200 (NZST)
  7. From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
  8. To: gep2@terabites.com, icon-group@optima.CS.Arizona.EDU
  9. Subject: Re: Error messages
  10. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  11. Status: RO
  12. Content-Length: 941
  13.  
  14.     > And then there is another matter: The instructions must be provided to the 
  15.     processor (Pentium) in the optimal sequence, making sure the pipelines are full 
  16.     at all times (as far as possible).
  17.     
  18.     That was more of an issue in the days when there was one overwhelmingly dominant 
  19.     microprocessor out there.
  20.  
  21. But there is a role for processor-model-specific scheduling.
  22. This is where an assembler-source to assembler-source front end in a
  23. compact high level form, relatively easy to plug new model-specific
  24. information into, could really pay off.  It's not really practical for
  25. someone to write 10 different highly-tuned versions of a piece of
  26. assembly code, but it _might_ be practical for them to write one clean
  27. generic piece and let the front end adapt it.  It would even be practical,
  28. in such a system, to plug in advice that is specific to the file being
  29. assembled.  Just think of the variation there is in graphics support opcodes.
  30.